[ ResourceManagementStories | ProjectIndex ] Managers focus primarily on cost and schedule. One hears few good stories about predicting schedules well. Do you have one to tell? Relate it here. If we see a pattern in enough of the wtories, we'll work on making it a pattern. Don't forget to sign your name. And edit your story carefully -- once you press Save, you can't edit it further. (If you really mess things up, write me at cope@bell-labs.com and I'll tidy things up.) A crunch-mode project scheduling and management tool that I've had good luck with several times is pretty low-tech: a big whiteboard and a bunch of colored stickies. Draw a timeline across the top of the board, and add lines for people. Then start laying out the (remaining) work. Let the team lay out their tasks, participate in shuffling, and later cross off tasks as they're completed. Besides being simple (and inherently multi-user), this tool avoids the "pert chart as holy artifact" problem that often results from high-tech tools. Everyone can partipate in the low-tech approach. And hands-on leads to buy-in, which is often overlooked as a factor in schedule predictability. I've used this technique several times, most recently as a defensive move to avoid a death march in a project that had gone out of (schedule) control. Here, to make sure that the newly re-created schedule was visible to upper management, we set the whiteboards up in a well-traveled hallway. --WikiWiki**!**DaveSmith At my current job, our VP put whiteboard calandars up in the hallway, with the various projects' progress and deadlines marked with post-it notes. My (newly departed) ex-boss was a Gantt chart fanatic. She'd listen to various people, and come up with some due-date for the projects, then try to squeeze the project into this timeline. I don't remember where I read this, but she was "managing backwards from a date." (Maybe it was FredBrooks? who said to not do that(?)) When I pointed out to her that this was bad, she insisted that it was the correct way to do things. I realized that it was futile to explain the iterative/incremental approcah, much less a SCRUM-like method (which I currently like). --DavidHooker Lot's of scheduling tools are used this way - Working backwards from a date. I am afraid that is what some managers want, often under pressure of marketing. You may have read "Dates are always difficult to estimate; DeMarco notes that one of the most serious signs of a problem in trouble is a schedule worked backward from an end date [DeMarco?]" at TakeNoSmallSlips. --- MartineDevos I used the PersonalSoftwareProcess by WattsSHumphrey to measure my work for a couple of months, and discovered an interesting rule: The time it took me to test a module was always within 10% of the time taken to complete the 'Code' stage. Later, on a one-month project, I noted that I was three weeks in, analysis and design had taken all of week one, and I had only just finished the code stage. I told management that I needed an extra week to do a proper job of testing at this point, and I was right. (Of course, they forced it out the door at the end of week 4 anyway, but that's politics, not accurate estimation.) -- NickArgall?
Project Scheduling Stories
[ ResourceManagementStories | ProjectIndex ]
Managers focus primarily on cost and schedule. One hears few good stories about predicting schedules well. Do you have one to tell? Relate it here. If we see a pattern in enough of the wtories, we'll work on making it a pattern.
Don't forget to sign your name. And edit your story carefully -- once you press Save, you can't edit it further. (If you really mess things up, write me at cope@bell-labs.com and I'll tidy things up.)
A crunch-mode project scheduling and management tool that I've had good luck with several times is pretty low-tech: a big whiteboard and a bunch of colored stickies. Draw a timeline across the top of the board, and add lines for people. Then start laying out the (remaining) work. Let the team lay out their tasks, participate in shuffling, and later cross off tasks as they're completed. Besides being simple (and inherently multi-user), this tool avoids the "pert chart as holy artifact" problem that often results from high-tech tools. Everyone can partipate in the low-tech approach. And hands-on leads to buy-in, which is often overlooked as a factor in schedule predictability.
I've used this technique several times, most recently as a defensive move to avoid a death march in a project that had gone out of (schedule) control. Here, to make sure that the newly re-created schedule was visible to upper management, we set the whiteboards up in a well-traveled hallway.
--WikiWiki**!**DaveSmith
At my current job, our VP put whiteboard calandars up in the hallway, with the various projects' progress and deadlines marked with post-it notes.
My (newly departed) ex-boss was a Gantt chart fanatic. She'd listen to various people, and come up with some due-date for the projects, then try to squeeze the project into this timeline. I don't remember where I read this, but she was "managing backwards from a date." (Maybe it was FredBrooks? who said to not do that(?))
When I pointed out to her that this was bad, she insisted that it was the correct way to do things. I realized that it was futile to explain the iterative/incremental approcah, much less a SCRUM-like method (which I currently like).
--DavidHooker
Lot's of scheduling tools are used this way - Working backwards from a date. I am afraid that is what some managers want, often under pressure of marketing. You may have read "Dates are always difficult to estimate; DeMarco notes that one of the most serious signs of a problem in trouble is a schedule worked backward from an end date [DeMarco?]" at TakeNoSmallSlips. --- MartineDevos
I used the PersonalSoftwareProcess by WattsSHumphrey to measure my work for a couple of months, and discovered an interesting rule: The time it took me to test a module was always within 10% of the time taken to complete the 'Code' stage.
Later, on a one-month project, I noted that I was three weeks in, analysis and design had taken all of week one, and I had only just finished the code stage. I told management that I needed an extra week to do a proper job of testing at this point, and I was right. (Of course, they forced it out the door at the end of week 4 anyway, but that's politics, not accurate estimation.) -- NickArgall?